Hmm what’s this for? Should still work on 32 bit

@WillAyd Can you please look at the reasons b38f9e6 failed.

That's what I am understanding, from looking at it.

Maybe you have other conclusions.

I think its just a bug somewhere; we typically don't default back to platform ints

@WillAyd Should I put a pytest.mark.skipif decorator (skiping this test, if running on 32-bit platform) at least for now?

Probably better to xfail than skip here; don’t think it matters when used imperatively but former would be more fitting

is this something that should be supported but isnt?

is this something that should be supported but isnt?

I am not sure.

is this not supported as in "not meaningful and so never will be supported" or as in "we havent gotten around to it yet so the behavior is wrong"? only the latter should be xfail

I am not sure, maybe @jorisvandenbossche knows?

It's hard to see what the test is actually testing, but I would think something like this?

In [5]: pd.Series([True]) * 3 
Out[5]: 
0    3
dtype: int64

but that doesn't fail, though.

But I agree with @jbrockmendel: if there are cases that it raises an error purposefully, we should test that and not xfail.

I am not able to test this without having if/else statement in the code, which is not really a pattern we want in our tests (I think), Any thought on how to write this test case?

The if/else might be fine, but in this if block, you can do a pytest.raises instead of xfail?

Trying to test the actual errors, will result in having a test case that looks somewhat like this:

   @pytest.mark.parametrize(
        "op",
        [
            operator.mul,
            ops.rmul,
            operator.floordiv,
            ops.rfloordiv,
            operator.truediv,
            ops.rtruediv,
            operator.pow,
            ops.rpow,
            operator.mod,
            ops.rmod,
        ],
    )
    @pytest.mark.parametrize("num", [np.int64(1), 1, 1.0])
    def test_array_like_bool_and_num_op_coerce_raises(self, op, num, box_with_array):
        # https://github.com/pandas-dev/pandas/issues/18549
        bool_box = [True]

        if op.__name__ in {"foo", "bar", "baz"}:
            msg = "|".join(
                [
                    "can't mod complex numbers",
                    "can't take floor of complex number",
                    r"unsupported operand type\(s\) for %: 'float' and 'Index'",
                    "cannot perform __foo__ with this index type: Index",
                ]
            )

            with pytest.raises(TypeError, match=msg):
                expected = [op(num, num)]
            return
        else:
            expected = [op(num, num)]

        bool_box = tm.box_expected(bool_box, box_with_array)
        expected = tm.box_expected(expected, box_with_array)

        if op.__name__ in {"foo", "bar", "baz"}:
            msg = "|".join(["cannot perform __foo__ with this index type: Index"])
            with pytest.raises(TypeError, match=msg):
                tm.assert_equal(expected, op(bool_box, num))
        else:
            tm.assert_equal(expected, op(bool_box, num))
        tm.assert_equal(expected, op(num, bool_box))

This looks sloppy, and not really readable, any thoughts?

That looks fine to me in general (have some comments on some details, but that will be easier to add when this is in the diff)

complex(1), np.int64(1), ... We may even have a fixture just called "one"

nitpick, the pattern we usually use is:

bool_box = [True]
expected = [op(num, num)]

bool_box = tm.box_expected(...
expected = tm.box_expected(...

result = op(bool_box, num)
tm.assert_equal(...
result = op(num, bool_box)
tm.assert_equal(...